1. Field of the Invention
The present invention relates to techniques for performing hardware and software co-verification testing as part of verifying the design of a data processing system.
2. Description of the Prior Art
The ability to effectively and efficiently test and/or validate designs is becoming increasingly important. Typical data processing system designs are rapidly increasing in complexity and furthermore are including circuit blocks designed by a variety of different sources or companies. So-called System-on-Chip (SoC) designs that integrate a large number of functional elements on a single integrated circuit have strong advantages in terms of cost and performance, but require significant amounts of validation and testing before the designs can be reliably released for manufacture. This validation and testing requirement is becoming a bottleneck in getting new systems into the market place. Consequently, measures that can improve the efficiency and effectiveness of such validation and testing of designs are strongly advantageous.
U.S. patent application Ser. No. 09/994,023 describes a technique for performing hardware simulation using a test manager. FIG. 1A illustrates the technique discussed in that patent application. FIG. 1A discloses a verification environment 10 formed of a hardware simulation 140, a plurality of signal interface controllers 35, 40, 45, 120, 125, 130, and a test manager 20. The hardware simulation 140 represents at least a portion of a System-on-Chip on an integrated circuit modelled as Register Transfer Language (RTL), for example Verilog or VHDL, using known hardware modelling computer programs. Such hardware modelling computer programs given RTL definitions (other types of definition are also possible) of circuit designs are able to simulate the processing activity of those designs by propagating signals throughout the designs and observing responses to those signals. The techniques of hardware simulation using RTL models are well known from commercially available systems.
In the example illustrated in FIG. 1A, the hardware simulation 140 includes a bus matrix 70, in this example the bus matrix conforming to the Advanced Microcontroller Bus Architecture (AMBA) protocol developed by ARM Limited of Cambridge, United Kingdom, and further includes three devices under verification (DUVs) 90, 95, 100 connected to the bus matrix via respective buses 75, 80, 85.
The hardware simulation 140 is supplied with stimulus signals from, and returns response signals to, associated signal interface controllers 35, 40, 45, 120, 125, 130 that are also referred to herein as eXtensible Verification Components (XVCs). These signal interface controllers are connected to corresponding buses 55, 60, 65, 105, 110, 115 within the hardware simulation 140.
The modular nature of the design being simulated by the hardware simulation 140 allows it to be considered as a plurality of hardware blocks. These hardware blocks typically have their own external interface requirements that do not vary between the different designs in which they are used. Thus, a block within the hardware being simulated and its associated XVC are likely to remain unchanged, or substantially unchanged, between different designs. Thus, by building up a plurality of XVCs from a library of these XVCs, a stimulus and response interface for a whole new design as a whole may be rapidly assembled.
The action of the separate XVCs is co-ordinated by a test manager 20. The test manager 20 is responsive to pre-programmed test scenarios 25, which are written by a test engineer or machine generated to provide random state coverage, to issue test scenario controlling messages over path 30 to the various XVCs 35, 40, 45, 120, 125, 130. These test scenario controlling messages specify simulation actions to be performed by the target XVC as well as specifying when that simulation action should be performed. The simulation actions can take a wide variety of different forms depending upon the hardware block to which the particular XVC relates. Typically, the master XVCs 35, 40, 45 have simulation actions to either drive directed FRBM (File Reader BUS Master) format vectors 50 onto the associated bus, or to generate random patterns of transfers constrained by a user configuration file. FRBM is an ARM Limited proprietary format used to stimulate AMBA bus signals, for example AHB, APB or AXI, in order to perform read and write transfers on a bus interconnect.
The above described approach is used for hardware integration performance testing and provides a flexible approach for such testing. However, it does not provide any mechanism for coordinating a software based scenario running on a processor. This problem can be illustrated with reference to FIG. 1B, which shows the verification environment of FIG. 1A, but with the addition of a representation of a processor 150 provided within the hardware simulation 140. Software to be executed by the processor can be provided as user test code 190, which can be compiled and linked in a standard manner in order to load that software into the ROM 185. The processor can then execute the software by retrieving instructions from the ROM 185 via the bus matrix 70 and the memory controller 165 using the buses 155, 160 and 175. Further, a RAM 180 accessible via the bus 170 can be used for storing data used by the processor when executing the instructions.
As can be seen from FIG. 1B, the XVC verification methodology can be employed to transfer stimulus signals and/or response signals to and from the hardware simulation 140, whilst the processor 150 is executing software stored within the ROM 185, but there is no co-ordination between the software routines executing on the processor 150 and the verification testing being performed under the control of the test manager 20. Hence, the prior art techniques described above with reference to FIGS. 1A and 1B cannot readily be used to perform co-verification of hardware and software.
One known technique that aims to provide for such hardware and software co-verification is the Mentor Seamless CVE (Co-Verification Environment) product, details of which are provided in the article “Core Based SoC Design System Verification Challenges” published on the Website www.mentor.com. A general overview of the technique provided through use of this product is illustrated in FIG. 2. The Seamless™ tool allows verification tests to be performed on hardware representations as well as the execution of software routines to interact with said hardware representations. In operation the Seamless™ kernel 220 processes all the bus requests coming from the co-verification simulator 200 (an instruction set simulator running software). For each instruction or data request, the kernel 220 can choose to supply data either directly from the memory model in the co-verification memory 250 or by exercising the bus-interface model (BIM) 230, which is included as a “black box” model with the hardware simulator 240. The memory model also has a port connected to the hardware simulator. The debugger 205 is used to debug the software running on the co-verification simulator 200.
Assuming that the user has correctly implemented a bus connection between the processor bus and the memory (i.e. over path 215, 220, 225, 230, 235, 240, 255), then the data will be read from the memory model through the hardware simulation 240 and into the BIM 230. Once the user has established that the hardware design for the memory sub-system is correct then the kernel can be instructed to map all instruction and data memory areas, in the memory map, to use the high-speed direct access route (i.e. the route over path 215, 220, 245). Work can then focus on the interfaces to peripherals that remain mapped in the hardware simulator.
Proprietary algorithms within the kernel 220 decide how BIM pins should be manipulated during periods when direct access to the memory model is used, to keep the relationship between software execution state and the hardware simulation state consistent.
The limiting factor in terms of software execution performance is the execution speed of the hardware simulator 240. This can be offset by judicious use of the Seamless™ optimization features (i.e. the direct access to memory over path 245).
A Co-Verification Controller (CVC) technique described in GB-A-2,374,435 uses a verification environment provided by Specman, Seamless CVE and ModelSim to form the basis of a software/hardware co-verification testbench. The RPC technique described in that patent application adds the ability to stimulate, monitor and check an IP block (i.e. hardware simulation) through its software interface. This is an important advance that allows IP blocks to be supplied with re-useable system verification components.
With this technique, the software is tested in the context of the hardware that it drives using the high-level verification generation and coverage facilities of the testbench. Furthermore, because the software and hardware models are accessible at the same time, it is possible to set up tests that would be impractical in other environments.
The earlier-described Mentor Seamless approach, and the technique described in GB-A-2,374,435 (which makes use of the Mentor Seamless technique) employ a mechanism specific to the Seamless™ tool to access a shared memory directly when seeking to perform co-verification of the software executing on the co-verification simulator 200 whilst also performing verification of the hardware simulation 240. Although this mechanism can work well, it does not scale well with models that incorporate more than one processor, nor can it readily be migrated to testing of hardware at different abstraction levels, for example silicon level testing. Further, when employing the Mentor Seamless technique described with reference to FIG. 2, it will be appreciated that there is no direct co-ordination between stimulus input from the hardware simulator 240 and software execution state. Although the technique described in GB-A-2,374,435 does allow the co-ordination or hardware stimulus and execution of software routines, this is restricted to operation on a device-by-device basis, and there is no single entity which is in control of the test procedure.
Accordingly, it would be desirable to provide an improved technique for performing hardware and software co-verification testing.